home *** CD-ROM | disk | FTP | other *** search
/ Best of Shareware / Best of PC Windows Shareware 1.0 - Wayzata Technology (7111) (1993).iso / mac / ZIPPED / WINDOWS / TELECOMM / WX16.ZIP / XFER.TXT < prev    next >
Text File  |  1992-02-07  |  7KB  |  115 lines
  1.  
  2.                  
  3.               MODEM TO MODEM FILE TRANSFER PROTOCOLS
  4.  
  5.      With the increasing use of modems for transferring large files,
  6. transfer protocols are becoming more and more widely used.  At the
  7. same time, more and more different protocols are being used.  Now,
  8. with the arrival of high speed modems, and the sending of much larger
  9. files, the particular protocol that is used is becoming far more
  10. important.  Here, we will take a brief look at various protocols, and
  11. then examine the elements involved in deciding what sort of protocol
  12. to use and what to consider when designing a protocol.
  13.  
  14.  XMODEM
  15.  
  16.      Perhaps the most famous protocol is XModem.  Developed by
  17. Ward Christensen, this protocol rapidly took hold, quickly becoming the
  18. "standard" file transfer protocol.  As far as protocols go, it is a
  19. very simple and straightforward one.  There are, however, a few oddities
  20. about it.  The most important, as far as the user of XModem is concerned,
  21. is the fact that there are two different error checking methods that can
  22. be used:  a checksum (ie.  the sum of the ASCII values of all the characters
  23. sent in that block), or a CRC, meaning Cyclic Redundancy Check, another form
  24. of error detection.   According to the definition of XModem, a CRC check
  25. is always performed first, and, failing that, the checksum method is used.
  26. This can cause problems when one of the two machines involved in the
  27. transfer is using a variety of XModem that does not follow these
  28. specifications.  The only other notable oddity of XModem is that it uses a
  29. very rigid timing sequence, which can cause problems on large multi-
  30. user systems, where the processor delays occur.  Some communications
  31. software supports a version of XModem in which the timing becomes less
  32. critical, but this is by no means a standard.  Apart from that, XModem is
  33. very simple and straightforward -  A 256 byte block is sent, along with
  34. error check information, and if the block is determined to be "bad", then
  35. a request to re-send is issued; otherwise the next block is started.
  36. While XModem is not a particularly efficient protocol, it is easy to use,
  37. and, most importantly, very common.
  38.  
  39. YMODEM
  40.  
  41.      YModem is little more than an XModem variant.  Its main difference
  42. lies in the fact that 1024 byte blocks are used, rather than the 256 byte
  43. blocks of XModem.  Some varieties suppose a mixed 1024 and 128 byte block
  44. system, but this is the exception rather than the rule.  (The idea behind
  45. the 128 byte block is that on a noisy line, with frequent errors, it is
  46. more efficient to send a smaller block - there is less chance of an error
  47. occurring in it).  The larger blocks make for an increased transfer speed,
  48. because YModem checks for errors once where XModem would have checked four
  49. times.  On a large file, this can make an appreciable difference.
  50.  
  51. KERMIT
  52.  
  53.      Kermit was developed at Columbia University, and is also very
  54. popular.  Kermit includes all sorts of features, such as the ability to
  55. transfer files between 7 and 8 bit systems, data compression, sending file
  56. names and attributes, and sliding windows.  It is the sliding windows that
  57. really sets Kermit apart from the XModem variety of protocols.  Essentially,
  58. Kermit operates in a full duplex mode.  Whereas XModem waits for the
  59. acknowledge sequence before sending the next block, Kermit allows the two
  60. machines to send data simultaneously, thus eliminating the wait time while
  61. the block is checked and confirmed.  This greatly speeds the transfer of
  62. files, and block size becomes virtually irrelevant.  Unfortunately, not
  63. all varieties of Kermit support sliding windows, as this was a later
  64. enhancement.  Because of Kermit's sliding window, small blocks are generally
  65. used, often 90 bytes.  Kermit also includes what are called server
  66. commands.  This allows commands to be sent to the host computer (assuming
  67. that it is operationg in the Kermit server mode).  As these commands are
  68. not really related to protocols in gerneral, we won't go into them here.
  69.  
  70. OTHERS
  71.  
  72.      Any other protocol can be considered a variant of the ones detailed
  73. above.  For example, WXModem (Windowed XModem) is simply an XModem with
  74. the sliding windows of Kermit.  Modem7 and Telink are XModem variants
  75. that include file headers (blocks of code that specify the name of the
  76. file), permitting multiple file transfers.  YModem batch is YModem that
  77. includes these file headers.  There are countless others, but the
  78. differences between them are too slight to be worth mentioning.
  79.  
  80.      When deciding which protocol to use, there are many things to
  81. consider, but a few general rules can make the decision much easier.
  82. Firstly, a sliding window protocol is always faster than the same
  83. protocol without the sliding windows.
  84.  
  85. Next, we get to block size.  For clean, clear lines, with good modems,
  86. the larger the block size, the more efficient the protocol.  Conversely,
  87. the noisier the line, the more efficient a small block becomes.  There is,
  88. unfortunately, no easy way to determine the state of the line prior to
  89. the transfer.  Remember, though, that small blocks mean little to sliding
  90. window protocols, as they are not slowed by the error check, so you
  91. can rid yourself of the block size worry by using one of them.
  92. Another important factor to consider is the nature of the system sending the
  93. file.  No matter what protocol you use, if the other system is using
  94. "Uncle Joe's 94% Compatible Protocol", you may run into trouble.  It is
  95. sad to see that some software manufacturers have strayed from the precise
  96. specifications in the interests of easy programming, especially where some
  97. of the more advanced protocols come into play.  For this reason, when using
  98. a strange or unknown system, it is often best to use one of the plain
  99. protocols, such as XModem or YModem.  Other than these words of advice,
  100. you're on your own.  With a little bit of experimentation, you can quickly
  101. discover which protocol gives you the best results on the systems that you
  102. use.  There is no one set "best" protocol.  Or, at least, not yet.
  103.  
  104.      We can expect to see a lot of new developement in future protocols, as
  105. programmers try harder and harder to reach that unattainable 100% efficiency.
  106. Guessing, I would say that the next developements will come in the area of
  107. data compression, although whether this will be done with hardware or
  108. software has yet to be seen.  Or, perhaps, the quest for the ideal protocol
  109. is already over, and now it's just a question of waiting for affordable
  110. high speed modems to solve the transfer problem.  One way or the other, we
  111. can safely say that the next five years hold a great deal in store for us.
  112.  
  113.  
  114. ======>>>  Let's talk about it!
  115.